Why

index.yaml is what datumctl reads, and it's fully derived from plugins/*.yaml. The current CI treats it as a reviewed source file: every PR must regenerate and commit it, and validation fails if it drifts. That puts generation work on:

• every human contributor, and
• the release bot — the update-plugin-index automation only edits plugins/<name>.yaml, so its catalog PRs fail the drift gate (#5 is exactly this: v0.3.0 opened, then failed Check index.yaml is in sync).

It was also the root of the earlier merge conflict on #1 — the same generated file edited on both a PR branch and main.

What

Treat index.yaml as a build artifact, reconciled automatically:

• Drop the index-sync gate from PR validation. PRs — human or bot — touch only plugins/*.yaml. Validation still schema-checks each manifest and verifies every download URL and checksum, so nothing broken can merge; only the generated index is no longer reviewed.
• Regenerate on merge (generate-index.yaml): a push to main that touches plugins/** regenerates index.yaml and commits it straight back to main. main is unprotected, so the built-in GITHUB_TOKEN pushes directly — no app token, no trailing chore PR. The commit changes only index.yaml (not plugins/**) and token pushes don't retrigger workflows, so it never loops; a concurrency group + rebase-retry covers closely-spaced merges.

Net: contributors and the bot edit exactly one file and never touch the index by hand.

Notes

• No change needed in datum-cloud/actions or the ipam release workflow — the generic update-plugin-index action keeps doing only what it should (edit the manifest).
• The scripts/generate_index.py generator is unchanged and still runnable locally to preview.
• Assumes catalog PRs come from same-repo branches (no forks), which lets the built-in token push the regenerated index.

Verification

actionlint clean on both workflows; the generator no-ops against the current in-sync main.